The present invention generally concerns electronics assembly engineering systems. In particular, the invention concerns methods of permitting naming and manipulation functions for data structures in data systems using transaction service within the environment of an electronics assembly engineering system. In particular, the invention concerns an electronics assembly engineering system having a computer subsystem incorporating computer-readable media for performing the methods and functions of the invention.
Electronics assembly engineering systems for industrial applications require complex and sophisticated subsystems to control performance of each system and to account for changes in the application parameters and the industrial environment. Control has traditionally been provided by computer subsystems. Some computer subsystems use object-oriented databases and transaction service in controlling performance. SIPLACE (by Siemens Electronics Assembly Systems, Inc., 2875 Northwoods Parkway, Norcross, Ga. 30071 USA), a platform used in the control of the production of printed circuit boards, is an example of an electronics assembly engineering system employing a subsystem using transaction service. SIPLACE employs a programming software subsystem known as SIPLACE Pro, which uses transaction service (in particular, Microsoft Transaction Server) to create and manage data structures, such as objects, within an object-oriented database. Using SIPLACE Pro, programmers can control performance of various aspects of the system through a user-friendly graphical interface. However, in this instance, where the electronics assembly engineering system and computer subsystem employ transaction service and the data structures have referential integrity, programmers working with the system can no longer expect to manipulate the data structures in the same manner as they did in traditional file-based systems.
Microsoft Word is an example of a traditional file-based application working within the file-system of the Microsoft Windows operating system. A user can manipulate files in a directory/file management system, such as Windows Explorer™, or within an editor. Similar results can be achieved in each environment, although the presentation of the functions can be different. When working in the directory/file management system, the file-system is represented by a tree-control. When working in the editor, the user is often presented with a dialog representing the file-system when, for example, “Save As” is chosen from the “file” menu within the Microsoft Word application.
The basic functionality and menu functions of a typical prior art file-based editor are shown in the flowcharts of FIGS. 1 and 2. FIG. 1 shows the functionality and menu functions of a prior art file-based editor in the mode where a new file is being created. FIG. 2 shows the functionality and menu functions of a file-based editor in the mode where an existing file is being edited. With reference to FIGS. 1 and 2, the menu functions of a traditional file-based editor are characterized as follows:
Manipulating Files within the Traditional Directory/file Management System (Prior Art)
Opening a file: A file can be selected in the tree-control and opened either from the context menu or by double clicking (the default function from the context menu). The user's intention is very clear that the file is to be opened in the appropriate editor, i.e. Microsoft Word.
Creating a new file: A new file of a registered type can be created without opening the application by selecting New→<Filetype> from the context menu. This creates the file in the selected folder. The file assumes a default name but is highlighted ready for immediate renaming if the user chooses to.
Renaming a file: The file can be renamed by selecting it and then, once selected, selecting the text of the file name a second time or by selecting it once and choosing the rename function from the context menu. The text of the filename can be edited directly.
Copying a file: A file can be selected and copied by choosing “Copy” from the context menu or from main menu Edit→Copy then using the paste command to create the copy in the desired location within the folder structure. The system is smart enough to rename the file if it is copied to the same folder. The copy function can also be achieved by holding down the control key when a drag is initiated—a copy of the file is created in the folder where the drop is made. The user's intention is clear, a new copy of the file is to be created.
Moving a file: A file can be selected and the “Cut” function chosen from the context menu or main menu Edit→Cut then the paste command can be used to effectively move the file to a new location. The file icon and name remain “grayed out” until “Paste” is initiated. A file can be moved to a different folder by selecting it with a sustained left mouse button and then dragging and dropping it to the new location on the same drive. (If the destination is on a different drive then a copy of the file is made.)
Deleting a file: A file can be deleted by selecting it and then choosing the “Delete” function from the context menu or with the delete keyboard button.
Creating Shortcuts: Selecting the file then choosing the Create shortcut function from the context menus can create a shortcut. Once a shortcut has been made the user can open it, delete it, move it, copy it and rename it in much the same way as if it were the source file. A new shortcut can even be created. The important feature of a shortcut is that when it is opened it is the source object that is opened. A shortcut created from a shortcut is equivalent to a copy of the shortcut—both link directly to the source file. In all other respects a shortcut is an independent file (of a special type) within the file system. A user has no expectation that the source file will be deleted when the shortcut is deleted and, conversely, there is no expectation that the shortcuts pointing to a file will be deleted when the source file is deleted—the shortcuts remain pointing to nothing. Worse than that, if a source file is deleted then later on a new file is created with the same name then the shortcuts will become active again.
Manipulating Files within the Application (Prior Art)
Open: When “Open” is selected from the File menu a dialog is opened that allows the user to choose an existing file from the file system using a tree control.
New: When “New” is selected from the file menu the user can then select a template for the new document (including the blank document template). The application then creates a file with a default name and puts this in the editor window. This “file” does not really exist in the file-system at this point.
Save: “Save” is typically a background function. The user chooses “Save” from the File menu and the file in the files system is immediately updated with the contents of the editor. The only exception to this is when a file is saved for the first time after it is created which is described below.
Save As: “Save As” is a slightly ambiguous dialog as it covers about three separate functions in a rather clumsy manner.
Save As—Simple—Giving a new file a name: When a file is closed for the first time or when “Save” is chosen for the first time the user is presented with a dialog that shows the default name and the current folder. The user is free to change the text of the name or select another folder.
Save As—To make a copy: If an existing file is in the editor then the Save As dialog can be used to create a copy of the changed file under a different name or in a different folder. In doing this, the original file is left unchanged—the original file and the copy can have different contents at this point.
Save As—To overwrite another existing file: If Save As is selected from an open editor, whether the document is new or existing, it is possible to select an existing file from the file-system and save the document under that name. In this instance, the “Do you want to overwrite the existing file” message appears and the contents of the editor can be saved to the existing file. In this case, the contents of the original file may be unchanged and the overwritten file will have been completely changed. A special case exists when an existing file's own name is selected from this dialog this generally will have the same effect as Save.
Close: A “necessity” of a file-based system is the customary “Do you want to save before closing?” when an editor is closed and changes to the file have not already been saved. Although this could have been avoided in the early days of computer use it is now a standard idiom. When a file is edited it is plain for all to see that there are (at least) two copies of the file—one in memory for editing and one in the file-system. It is reasonable, since there is the possibility of discarding recent changes, to offer the user the choice of discarding the changes and to leave the copy in the file system unchanged. This also leads to the cascading into the “Save As” dialog if the new file has not been named before closing.
The naming and manipulation functions of the traditional file-based systems are not adequate for operating in object-oriented systems using transaction service where data structures have referential integrity. This is especially true when such systems are used in electronics assembly engineering applications. The inadequacy results from several differences between the typical file-system and the object-oriented database using transaction service (such as SIPLACE Pro). These differences lead to quite substantial changes in the overall appearance of the application in the object-oriented system.                From the user's point of view the object browser and the editor are combined within the client application. The tree controls that allow navigation of the object database are side by side with the editors. The result is that the user does not see the object browser.        Objects that are opened in an editor are immediately updated when changes are made—there is no copy of the object in memory.        Objects can have many names or aliases—this leads to a certain amount of ambiguity in that an ordinary user may have trouble visualizing where an object exists. Objects are in a sense omnipresent; it is only their names that have a position in the hierarchy of the tree control.        The objects within the database have referential integrity—this results in links between objects that have greater significance than their names.        
Thus, a host of problems would arise if the basic functionality and menu functions of a typical file-based editor were utilized in an object-oriented database using transaction service. Therefore, it is a goal of the invention to provide naming and manipulation functions for user defined data structures in a data system using transaction service.